Do we store the bias voltages somewhere for these detectors?

I'm using the bias voltages to determine the mean electric field in the detector, to estimate their charge drift times.

And the same thing might also apply for the temperature (which might influence how much the charges diffuse)

Do we ever expect the charge transport to result in the energy deposited across more than 3 strips?

I'm not getting significant contribution to next-to-nearest neighbors for the energies I've look at so far (~1MeV in a single hit), but I can expand this also to next-to-nearest neighbors.

Also: if we run simulations with Simple detectors rather than clustering hits with Voxel3D, we might not expect individual hits with energies way higher than that, but rather a bunch of lower-energetic sub-hits.

So what I'm hearing is that if you keep it just as nearest neighbors then there might be a small loss of energy, but that'd probably be below a reasonable detectable energy so doesn't matter. Maybe just add a comment in the code to show you've thought this through?

I thought about this again this morning: we might still want to expand this to next-to-nearest neighbors, just because of the fact that the nearest neighbors might surpass the energy threshold to actually be considered triggered events, and then the next-to-nearest neighbor might still be read out as "nearest-neighbor" of the triggered strip.

Here you've defined a new DEEStripHit with the above parameters, but you don't retain some of the info that the SH previously had, such as m_SimulatedPosition. This position (or at least the variable m_SimulatedRelativeDepth) will need to be used in the depth SubModule. Maybe I'm misreading how you're clearing and defining events so that this info is still retained for the SH for future submodules to access?

I see, and I can check this.. My understanding was that by defining MainSH via SH, all the previous information from the simulation would still remain saved, and I would just be "adding" the new information from the charge transport.

Another question regarding your comment:
How should we deal with events with multiple hits within one strip, that would get merged later on? Should they keep the simulated position of the dominant hit? Or of the hit closest to the contact?

You're right about defining MainSH via sH. I missed that somehow.

Good question about the position from events with multiple hits! Are you referring to two interactions that share the same LV strip, but different HV strips, for example? If I'm understanding your code right, you're combining the energy of multiple hits per strip in your iteration starting at line 193. So you no longer have two separate hits clearly defined with separate positions? If so, I'm wondering if this is the right place to make this combination or if we can keep the hits separate until we get to the DepthReadout where we can handle the timing of each hit properly.
We'd want this to mimic the hardware as much as possible. I assume the strip hit is assigned the timing of the closest hit as long as it's above the fast threshold, right? So I don't think you could easily determine the correct position to use here without doing the inverse depth calibration to get timing for each strip hit and have fast threshold knowledge.

This was code that @zoglauer introduced in his initial DEE implementation (c527242) and that I didn't touch so far.
From what you are saying, it might make sense to combine those hits only once the simulated information (energy, position) of the individual hits are not needed anymore, maybe in MSubModuleStripReadout or MSubModuleDEEOutput (?).

The fast shaper is supposed to trigger on the first peak above the fast threshold, which should correspond to the earliest timing of electrons and holes arriving. This situation gets a bit more complicated in charge-sharing signals, where the fast shaper signal is not necessarily "just a peak", but might exhibit somewhat of a peak-dip structure, resulting in slightly earlier triggering than what is expected from the electron- and hole-arrival times. This might become particularly relevant, if we want to be able to simulate things like NN timing for bump corrections.

Yes, I think the hits should be combined either in the DepthReadout or in the DEEOutput. The StripReadout only handles the inverse energy calibration, but we'll need the hit positions separate for the inverse depth calibration for an accurate handling of the timing for each hit. Again, I'm fine with this as is for now, but keep this in mind as we progress with the fidelity of the DEE.

So what I'm hearing is that if you keep it just as nearest neighbors then there might be a small loss of energy, but that'd probably be below a reasonable detectable energy so doesn't matter. Maybe just add a comment in the code to show you've thought this through?

You're right about defining MainSH via sH. I missed that somehow.

Good question about the position from events with multiple hits! Are you referring to two interactions that share the same LV strip, but different HV strips, for example? If I'm understanding your code right, you're combining the energy of multiple hits per strip in your iteration starting at line 193. So you no longer have two separate hits clearly defined with separate positions? If so, I'm wondering if this is the right place to make this combination or if we can keep the hits separate until we get to the DepthReadout where we can handle the timing of each hit properly.
We'd want this to mimic the hardware as much as possible. I assume the strip hit is assigned the timing of the closest hit as long as it's above the fast threshold, right? So I don't think you could easily determine the correct position to use here without doing the inverse depth calibration to get timing for each strip hit and have fast threshold knowledge.